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REMARKS 

Rejections under 365 U.S.C> §102fa) 

The Examiner rejected claims 1-9 and 12-15 as being anticipated by 3GPP TR 
23.846 (1/2002), hereinafter TR23846. Applicant incorporates all of the arguments 
(presented again below) in the Response filed on 22 January 2010. 

Regardless, Applicant has amended claims 1,2, 12, 16, and 17 to ftirther 
distinguish these claims over the cited reference. Each of the independent claims 1, 12, 16, 
and 17 has been amended. For instance, claim 1 now recites "setting up said second number 
of connections between said first switching node and said second switching node, wherein 
said second number is at least two". Similar subject matter has been added to claims 12, 16, 
and 17. As discussed in detail below, there will, however, be only a single Gn OTP tunnel in 
TR23846 between the GGSN and the SGSN to support the specific MBMS service. In other 
words, in TR23846, there could be one, two, or hundred lu GTP tunnels, but only a single Gn 
GTP tunnel to support a specific MBMS service. Thus, the added subject matter to 
independent claims 1, 12, 16, and 17 fijrther distinguishes over the cited reference. . 

Applicant respectfully submits that all present claims are therefore patentable 
over TR23846 and requests the rejections to these claims be removed. 

Arguments from the Response filed on 22 January 2010 

TR23846 does not disclose all elements of Applicant's independent claims. In 
fact, TR23846 teaches away from the invention and teaches a completely different technique. 

The Examiner notes that TR23846 was cited by Applicant and described in 
Applicant's specification. In Applicant's specification, Applicant describes TR23846 in the 
following manner (emphasis added): 
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[0005] The MBMS is defined e.g. in the 3GPP specifications 
TS 22.146 and TR 23.846 as a point-to-multipoint bearer service which 
provides the above capability for broadcast/multicast services. [] 

[0006] In the known MBMS architecture as defined in the 
above specifications, a SGSN and a GGSN maintains one or many logical 
connection(s) in order to route MBMS data to relevant UEs. The SGSN 
duplicates data packets received from the GGSN through a single GPRS 
Tunneling Protocol (GTP) tunnel and forwards the received data packets 
and duplicated data packets, respectively, via corresponding GTP tunnels 
to each RNC involved in the provision of a specific MBMS service. The 
GGSN duplicates data packets received from the MBMS data source for 
forwarding to each SGSN to which a GTP tunnel has been established for the 
specific MBMS service. 

[0007] However, due to the fact that only one GTP tunnel is 
established between the GGSN and the respective SGSN , considerable 
changes are required at the SGSN to provide additional processing power and 
logic functionality for packet duplication and adaptation of individual logical 
connection parameters at the SGSN. 

In the above text, it is implied that there are potentially multiple GTP tunnels from a single 
SGSN to multiple RNCs in TR23846. For instance, the reason the SGSN duplicates data 
packets is to be able to send the data packets to multiple RNCs (each RNC therefore receiving 
one of the duplicated sets of packets). However, in TR23846 there is only a single GTP 
tunnel established between the GGSN an SGSN to support a specific MBMS service. 

FIG. I ("MBMS Architecture") of TR23846 is reproduced below: 
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TR23846, FIG. 1, section 6.1. Putting this in the context of FIG. 1 of TR23846, there may be 
multiple lu GTP tunnels between the SGSN and the RNCs (not shown) in the UTRAN to 
support a specific MBMS service. There will, however, be only a single Gn GTP tunnel 

between the GGSN and the SGSN to support the specific MBMS service. In other words, in 
TR23846, there could be one, two, or hundred lu GTP tunnels, but only a single Gn GTP 
tunnel to support a specific MBMS service. 

Nothing in TR23846 states anything other than what has just been described. 
TR23846 states the following: 

In the MBMS architecture the SGSN performs user individual 
service control functions and the SGSN concentrates all individual users of the . . 
same MBMS service into a single MBMS service. The SGSN maintains a 
single connection with the source of the MBMS data. The SGSN duplicates 
the packets received from the GGSN for forwarding to each RNC 
involved in provision of a soecific MBMS service. 

The GGSN terminates the MBMS GTP tunnels from the SGSN 
and links these tunnels via IP multicast with the MBMS data source. The 
GGSN duplicates the packets received from the MBMS data source for 
forwarding to each SGSN to which a GTP tunnel is established for a 
specific MBMS service . 

TR23846, section 6.1 (emphasis added). 

Furthermore, see the following: 

Besides the user individual service control functions 
comparable to the functions already provided by an SGSN or GGSN there are 
some additional functions required for MBMS, mainly the specific data 
transport. It is assumed, that the SGSN performs the user individual service 
control, generates the charging data per user and establishes the RABs when 
MBMS data is to transfer. The SGSN concentrates all user individual 
services into one MBMS service for each specific MBMS service. This 
includes the establishment of a number of RABs to transfer MBMS data to 
the radio network entities of the related service area and it includes a single 
connection between the SGSN and the GGSN for each individual MBMS 
service . The SGSN duplicates the data received from the GGSN for each 
RAB established for the service. Similarly, the GGSN duplicates data 
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received from the MBMS source for each GTP tunnel related to the same 
MBMS service. 

TR23846, section 6.1.4 (emphasis added). In other words, "[t]he SGSN concentrates all user 
individual services into one MBMS service for each specific MBMS service", and there is a 
" single connection between the SGSN and the GGSN for each individual MBMS service" 
(emphasis added). In other words, a single connection between the SGSN and the GGSN for 
a single MBMS service, and the SGSN concentrates all user individual services into this 
single connection. However, between the SGSN and the radio network entities (e.g., RNCs), 
there will typically be multiple radio network entities and the SGSN duplicates the data in 
order send to the multiple RABs/radio network entities (e.g., RNCs). 

Because there is only a " single connection between the SGSN and the GGSN 
for each individual MBMS service" in TR23846, there is no need for the GGSN to be 
provided = the number of connections made by the SGSN to the multiple RABs/radio 
network entities (e.g., RNCs). 

Tiiming to claim 1, this claim recites the following: 

A method, comprising: 

providing to a first switching node information indicating a 
number of connections required between a second switching node and a 
plurality of terminal devices; and 

determining based on said provided information a number of 
connections to be set up between said first switching node and said second 
switching node of a data network to set up a broadcast or multicast 
transmission for a broadcast or multicast service to the plurality of terminal 
devices. 

The Examiner appears to liken the GGSN in TR23846 to a "first switching network" and the 
SGSN in TR23846 to the "second switching node". The Examiner states that TR23846 
discloses all elements of this claim, but it is respectfiilly submitted that this is incorrect. 
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TR23846 does not perform "providing to a first switching node [GGSN 
according to the Examiner] information indicating a number of connections required between 
a second switching node [SSGN according to the Examiner] and a plurality of terminal 
devices" because there is a " single connection between the SGSN and the GGSN for each 
individual MBMS service" (TR23846, section 6.L4 (emphasis added)). The GGSN in 
TR23846 has no reason to be informed of the number of connections between the SGSN and 
the terminal devices, because this number is immaterial: the number could be one, two, ten, 
one hundred, or a thousand, yet there is only a " single connection between the SGSN and the 
GGSN for each individual MBMS service" (TR23846, section 6.1.4 (emphasis added)). 

The subject matter of "determining based on said provided information a 
number of connections to be set up between said first switching node and said second 
switching node of a data network to set up a broadcast or multicast transmission for a 
broadcast or multicast service to the plurality of terminal devices" is also not disclosed by: 
TR23846. This is true because in TR23846, there is no reason to "determine[e] based on siaid 
provided information a number of connections to be set up between said first switching node 
[GGSN according to the Examiner] and said second switching node [SSGN according to the 
Examiner] of a data network to set up a broadcast or multicast transmission for a broadcast or 
multicast service to the plurality of terminal devices", because there is always only a " single 
connection between the SGSN and the GGSN for each individual MBMS service" (TR23846, 
section 6.1.4 (emphasis added)) in TR23846. 

The Examiner points to section 7.4, step 6, and section 7.5, step 1 1 of 
TR23846, arguing that because a new MBMS connection is created at these points, then "a 
number of connections have been determined": 
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a. With regards to determining "a number of connections", if one connection 
is used between the GGSN and SGSN, which was established as a result of a 
SGSN request, then a number of connections have been determined. Setting up 
one connection may appear trivial however is required as shown in section 7.4 
step 6 and section 7.5 step 11, where TR23846 discusses first checking if there 
is an existing MBMS connection and. if not creating a connection, therefore 
determining that a connection is required, which is made between the GGSN and 
the SGSN. Furthermore, as disclosed in TR23846 section 6.1.4, the SGSN 

Outstanding Office Action, page 3. What tiiese sections state is the following: 

The new SGSN validates the UE's presence. If due to roaming 
restrictions the UE is not allowed to be attached in the SGSN, or if 
subscription checking fails, the new SGSN rejects the routeing area update 
with an appropriate cause. If all checks are successful, the new SGSN 
constructs MM, PDP and MBMS contexts for the UE. The new SGSN 
checks each individual MBMS service indicated by the MBMS contexts of 
the UE. If it is the first UE with this specific MBMS multicast service on 
this SGSN the SGSN requests the creation of an MBMS context on the 
GGSN and the establishment of a GTP tunnel between the SGSN and the 
GGSN. 

TR23846, section 7.4, step 6 (emphasis in original). 

Upon receipt of the Relocation Detect message, the CN may 
switch the user plane from source RNC to target SRNC. If the SRNS 
Relocation is an inter SGSN SRNS relocation, the new SGSN sends Update 
PDP Context Request messages to the GGSNs concerned. The GGSNs update 
their PDP context fields and return an Update PDP Context Response. If the 
SRNS Relocation is an inter SGSN SRNS relocation, the new SGSN 
checks each individual MBMS service indicated by the MBMS contexts of 
the UE. If it is the first UE with this specific MBMS multicast service on 
this SGSN the SGSN requests the creation of an MBMS context on the 
GGSN and the establishment of a GTP tunnel between the SGSN and the 
GGSN. 

TR23846, section 7.5, step 1 1 (emphasis in original). 
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All these sections are stating, however, is that if there is no MBMS service on 
the current SGSN, an MBMS context is established between the GGSN and the SGSN via a 
single GTP tunnel between the SGSN and the GGSN, There is simply no disclosure that the 
SGSN provides to the GGSN information indicating a number of connections between the 
SGSN and the terminal device(s). And TR23846 teaches away from this, as there is always 
only a '' single connection between the SGSN and the GGSN for each individual MBMS 
service" (TR23 846, section 6.1.4 (emphasis added)) in TR23846. Thus, the GGSN in 
TR23846 has no need of "information indicating a number of connections required between a 
second switching node [SGSN according to the Examiner] and a plurality of terminal 
devices" as recited in claim 1 . ^ 

For at least these reasons^ TR23846 does not disclose either "providing to a 
first switching node information indicating a number of connections required between a 
second switching node and a plurality of terminal devices" or "determining based on said 
provided information a number of connections to be set up between said first switching node 
and said second switching node of a data network to set up a broadcast or multicast 
transmission for a broadcast or multicast service to the plurality of terminal devices". Claim 
1 is patentable over TR23846. 

Because claim 1 is patentable, independent claim 12 is also patentable over 
TR23846 for similar reasoning. Because independent claims 1 and 12 are patentable, 
dependent claims 2-9 and 13-15 are also patentable. 

Rejections under 35 U.S.C. § 103(a) 

The Examiner rejected claims 10 and 16 as being obvious over TR23846 in 
view of Leroy (EP 1071296). The Examiner rejected claims 11, 17, and 20 as being obvious 
over TR23846 in view of Mizell (U.S. Patent no. 7,289,462). 

With regard to claims 10 and 11, because independent claim 1 is patentable, 
claims 10 and 1 1 are also patentable for at least the reasons given above. Furthermore, 
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neither Leroy nor Mizell cure the defects of TR23846. Additionally, Applicant does not 
acquiesce to the Examiner's argument that these references can be combined with TR23846, 
but it is not necessary at this time to address this. Therefore, claims 10 and 1 1 are patentable 

over TR23846, alone or in combination with one or both of Leroy or Mizell. 

The arguments above with respect to claim 1 also apply equally as well to 
independent claims 16 and 17. For instance, claim 16 recites the subject matter of "access a 
memory table in order to derive information indicating a number of connections required 
between a switching node and a plurality of terminal devices" and "determine based on said 
derived information a number of connections to be set up to said switching node to set up a 
broadcast or multicast transmission for one multicast/broadcast multimedia service to said 
plurality of terminal devices". 

As described above, there is a " single connection between the SGSN and the 
GGSN for each individual MBMS service" (emphasis added). However, between the SGSN 
and the radio network entities (e.g., RNCs), there will typically be multiple radio network 
entities and the SGSN duplicates the data in order send to the multiple RABs/radio network 
entities (e.g., RNCs). Because there is only a " single connection between the SGSN and the 
GGSN for each individual MBMS service" in TR23846, there is no need for the GGSN to 
determine (e.g., by accessing a memory table) the number of connections made by the SGSN 
to the multiple RABs/radio network entities (e.g., RNCs). 

TR23846 does not perform the subject matter in claim 16 of "access a memory 
table in order to derive information indicating a number of connections required between a 
switching node and a plurality of terminal devices" or "determine based on said derived 
information a number of connections to be set up to said switching node to set up a broadcast 
or multicast transmission for one multicast/broadcast multimedia service to said plurality of 
terminal devices", because there is a " single connection between the SGSN and the GGSN 
for each individual MBMS service" (TR23846, section 6.1.4 (emphasis added)). The GGSN 
in TR23846 has no reason to determine the number of connections between the SGSN and 
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the terminal devices, because this number is immaterial: the number could be one, two, ten, 
one hundred, or a thousand, yet there is only a " single connection between the SGSN and the 
GGSN for each individual MBMS service" (TR23846, section 6.1.4 (emphasis added)). 

TR23846 does not perform the subject matter in claim 17 of "query, using a 
multicast identification or a multicast area identification, from an address server information 
indicating a number of connections required between said a switching node and a plurality of 
terminal devices" and "determine based on said queried information a number of connections 
to be set up to said switching node to set up a broadcast or multicast transmission for one 
multicast/broadcast multimedia service to said plurality of terminal devices", because there is 
a " single connection between the SGSN and the GGSN for each individual MBMS service" 
(TR23846, section 6.1.4 (emphasis added)). The GGSN in TR23846 has no reason to 
determine the number of connections between the SGSN and the terminal devices, because 
this number is immaterial: the number could be one, two, ten, one hundred, or a thousand, 
yet there is only a " single connection between the SGSN and the GGSN for each individual 
MBMS service" (TR23846, section 6.1.4 (emphasis added)). 

Furthermore, neither Leroy nor Mizell cure the defects of TR23846. 
Additionally, Applicant does not acquiesce to the Examiner's argument that these references 
can be combined with TR23846, but it is not necessary at this time to address this. 

Therefore, the subject matter of claims 16 and 17 are not disclosed by 
TR23846 or TR23846 in combination with one or both of Leroy or Mizell, and claims 16 and 
17 are patentable. 

Conclusion 

Based on the foregoing arguments, it should be apparent that claims 1-20 are 
thus allowable over the reference(s) cited by the Examiner, and the Examiner is respectfully 
requested to reconsider and remove the rejections. The Examiner is invited to call the 
undersigned attorney for any issues. 
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